SQL Server 2008 : Performance Tuning - Tracing

As the performance tuning exercise is refined, it becomes necessary to get visibility of activity within SQL Server, and this is when we need tracing. Tracing provides the ability to collect data about the Transact-SQL (T-SQL) commands and Multi-Dimensional Expressions (MDX) that are executed on a database server. Additionally it is possible to trace for information about events affecting system performance such as deadlocks, warnings, data and log file shrinks/grows, and blocked processes. Tracing can also gather information about the way SQL Server processes requests internally such as locks, lock escalation, and query execution plans.

SQL Server Profiler (known as SQL Profiler or simply as Profiler) is the graphic tool installed alongside SQL Server used to define, configure, and start/stop traces. SQL Server Profiler can be found at Start > All Programs > Microsoft SQL Server 2008 > Performance Tools > SQL Server Profiler.

Once Profiler is launched, a toolbar and grey background appears, and you’ll first need to create a new trace. To create a new trace, either click File > New Trace or click the left-most icon from the toolbar. The next screen is the server connection dialog; here, specify the name of the server and SQL Server instance to be traced, and connection credentials.

After successfully connecting to an instance of SQL Server, the next dialog allows control over how trace data is stored and what data is captured. As shown in Figure 1, it’s possible to provide a name that describes the trace.

Figure 1. Create a New Trace with SQL Server Profiler

Trace Templates

The next configuration option is the trace template option, where the Standard template is selected by default. Trace templates provide a preconfigured trace definition for common trace scenarios. It is possible to create new trace templates, or modify those provided with SQL Server. It is usually possible to start with a template and adjust the events and filters based on your needs. Table 1 contains a summary of the trace templates, when you might use them, and the events captured.

After you choose a trace template, it’s possible to click Run, and server activity will begin to fill the screen. This can be useful to verify the required events are being captured, or to monitor SQL instances where activity is low (a development workstation or test server where workload is restricted). However, reading and analyzing results captured through Profiler directly to the screen can become unwieldy on a server with even moderate load. In this situation, consider tracing to a flat file or database table, which will speed up the trace and allow for post-capture analysis.

Trace Events

Selecting the Events tab from the top of the trace properties dialog allows control of the event classes that will be captured when the trace is running. The events that are already selected are those specified in the trace template. Click Show All Events and Show All Columns to display all events and options available for capture.

You can choose any events that are necessary to include these in the trace definition. Figure 2 shows some useful events to include in each trace, the Errors and Warning events. These will alert you to a number of conditions that you should be aware of when troubleshooting any SQL Server problem.

Figure 2. Select Show All Events and Show All Columns to Display All Possible Events and Columns

Trace Filters

Trace filters allow restrictions to be applied on the data that is captured by the trace. This can be useful on particularly busy or shared servers when filters can be used to capture activity for a single user, database, or application. Filters can be applied to include (Like) or exclude (Not Like) trace data.

To apply a filter, click Column Filters from the Trace Properties dialogue and select the Column on which to filter. In the example shown in Figure 3 all requests from server LONDBS1 are excluded from the SQL Trace.

Figure 3. Use Trace Filters to Include or Exclude Specific Trace Data

Server-Side Tracing

Server-side tracing reduces the impact of tracing and is recommended when tracing busy production servers or machines where system resources (memory, CPU, etc) are low. Additionally, when traces are run from the server itself there is no network time involved in reporting start times for query execution. Since network time can vary (e.g., latency due to traffic of other network users), tracing across a network can produce inconsistent results.

There are two methods to create a server-side trace. As always a family of stored procedures are provided, which can be cumbersome and difficult to translate to actual events and columns. It is possible to create a trace within Profiler and then script the trace definition. To script the trace definition, select File > Export > Script Trace Definition > For SQL Server 2005–2008.

Open the trace definition in SQL Server Management Studio, and you’ll see the sp_trace_create statement to define the trace. Here you’ll need to replace InsertFileNameHere with the path to the folder where trace files should be saved (see Figure 4). Try to avoid tracing to system drives, or those where data or log files are stored, since this will affect performance of the database server.

Figure 4. Trace Definition Created by SQL Profiler

Once the destination is configured, run the script and make a note of the TraceID that is returned by the query. The trace is now defined on the server; however, there’s an additional step required to start the trace. The system stored procedure sp_trace_setstatus is used to control the trace, and requires parameters TraceID and status. Table 2 shows the status parameters. In order to start TraceID 2, we’ll need to run sp_trace_setstatus(2,1).

Finally, if you lose track of which traces are running on a server, run Select * from fn_trace_getinto(null) to return details of all traces. Remember that unless you’ve disabled it there’s a default trace running at all times to populate the DMVs; this will be TraceID 1.

Combining System Monitor and Profiler Traces

First introduced to SQL Server 2005, this excellent feature of Profiler allows Administrators to combine a System Monitor (Performance Monitor) trace with a SQL Trace. This presents a single view of system resources (disk, memory, CPU) with the statements executing at the time; for example, enabling Administrators to correlate high-CPU conditions with a specific stored procedure or T-SQL statement.

Figure 5 shows the timeline from System Monitor, which allows a view of hardware utilization. The red vertical bar allows administrators to jump to a particular point (e.g., a CPU spike), and the profiler trace will identify the T-SQL running at the moment of the spike.

Figure 5. Combining System Monitor and Profiler Traces for a Single View

Replaying Traces

SQL Server provides the ability to replay traces; typical scenarios involve capturing a trace from a production server and replaying the trace against a test or preproduction server. This can help when evaluating changes and also with some troubleshooting scenarios. Each statement captured in the trace will be replayed against the target server; this can be helpful in verifying that a fix implemented on a test server does resolve a problem.

There are a minimum set of events required for trace playback; alternately use the Replay trace template. Not all servers can be traced and replayed; for example, if the server is participating in Transactional Replication trace replay isn’t possible because of the way transactional replication marks transactions in the log.

SELECT * INTO srv1_trace FROM::fn_trace_gettable('c:\temp\trace1.trc',
default)

Once the data is in a database, analysis with TSQL queries is much easier!

Using SQLDiag to Collect Performance Data

SQLDiag is a command-line, data-collection utility first supplied with SQL Server 2005 that can useful for collecting performance data. SQLDiag collects the following:

• Windows Event Logs

• SQL Server Configuration details

• System Monitor Performance logs

• SQL Server Profiler Trace data

• SQL Server blocking information

Essentially, SQLDiag doesn’t do anything that couldn’t be achieved separately— each of these tools could be run independently, however SQLDiag it makes it easier to start and stop data collection and ensures all relevant information is collected each time data capture is run.